After connecting or installing a hardware device to a computer, there is a user expectation that the hardware device will work, i.e., that the computer will properly recognize, communicate and operate with the hardware device, and that through the computer, a user will be able to utilize that hardware device. Unfortunately, quite frequently, after a user has apparently connected or installed the hardware device to the computer, the computer and hardware device fail to communicate and/or inter-operate. In such circumstances, it is very difficult to determine the exact nature or source of the failure. For example, the failure may lie in an operating system problem, in faulty software for communicating with the hardware device, or in improper installation. In any event, the user is left to try to isolate the problem and rectify the situation.
Even after a hardware device is apparently installed and operating on a computer, it is not uncommon that the hardware device operates at less than its advertised or optimal performance, or that some features or aspects associated with the hardware device fail to operate entirely. Again, the user must determine whether the software that interfaces with the hardware device is faulty, whether the hardware device itself is faulty, whether the user incorrectly installed the device, or whether the operating system is at fault.
When faced with these problems, a user may refer to operator manuals for the hardware device and/or for the operating system, call a support service, check on the provider's Internet site, consult with user groups, and the like. However, a user is often unable to secure proper assistance because the user is unable to identify the exact source of the problem. As such, the user will frequently turn to the most visible and/or accessible information source, either an operating system provider or a hardware provider.
Operating system providers are a frequent, yet incorrect, target of dissatisfied users for various reasons, including the widespread use of the operating system, the fact that the operating system is a common denominator to the problem, and also, that the operating system provider often bundles device drivers for various hardware devices with its operating system, primarily for user convenience. For purposes of the present discussion, and as those skilled in the art will recognize, a device driver is a body of computer code that, when installed on a computer, acts as the interface for a specific hardware device for the operating system. In other words, device drivers represent the hardware/software interface between the operating system and the hardware device.
As one example of how operating system providers often bundle device drivers on deliverable media with their operating system, the distributable media for the most recent version of Microsoft Corporation's Windows® operating system includes bundled device drivers for approximately 10,000 different hardware devices! However, while an operating system provider, such as Microsoft Corporation, distributes or bundles numerous device drivers for user convenience, most device drivers are not actually written by the operating system provider. In fact, most device drivers are actually written by the corresponding hardware device provider, and submitted to the operating system provider for distribution purposes. This distribution mechanism also explains why hardware device providers offer updated device drivers: to correct “issues” with an earlier version of the device driver that was distributed by the operating system provider.
In spite of the fact that the operating system provider does not actually write the device drivers, because they distribute the device drivers, to a user it appears that the device drivers are “from” the operating system provider, and the dissatisfied user calls the operating system provider when a problem arises. Thus, it behooves an operating system provider to determine that a hardware device operates at a minimum level of compatibility with a computer running its operating system prior to bundling a device driver on its distribution media.
One area where the operating system provider looks to determine whether a hardware device (with its corresponding device driver) is compatible with a computer system is the communication between the hardware device and the device driver. Those skilled in the art will readily appreciate that in order for a hardware device to properly function on a computer system, the hardware device must communicate with the computing system, particularly with the operating system, according to some predetermined communication protocol. The device drivers, as the interface between the operating system and the hardware device, encapsulate this communication protocol. The communication protocol is almost always memorialized in a so-called communication specification.
The communication protocol may conform to a public communication specification, or alternatively, be implemented as a private communication specification. Examples of public communication specifications include the Universal Serial Bus (USB) specification and the IEEE 1394 specification (also referred to as Firewire). Private communication specifications are simply non-public communication protocols that are encapsulated in corresponding device drivers. Hybrid communication specifications, i.e., a combination of both public and private communication specifications, are also sometimes used. However, irrespective of whether a specification is a public or private communication specification, the communication protocol represented by the specification represents a set of rules by which a device driver and a hardware device should abide in order to properly communicate. Failure to follow those rules can result in computer system/hardware incompatibilities, reduced or failed hardware performance, irreparable damage to the hardware device's firmware, operating system failures, and the like.
Testing whether the communications between a device driver and a hardware device conform to an established specification is currently a difficult process. In addition to the sheer number of hardware devices available, according to current practices, in order to evaluate the communication between a device driver and a hardware device, one must locate and/or identify the communication stream as it flows between the device driver and the hardware device. Frequently, these communications may take place over system interrupts, register reads and writes, system port reads and writes, through shared memory blocks, and the like. One trying to locate the communications between a device driver and a hardware device must be well versed in monitoring a myriad of “events” occurring on a computer system, and filter out events and the like that are not related to the monitored communications. In addition to “merely” identifying the communications, in order to validate whether a device driver and hardware device communicate according to a communication specification, one must also evaluate the communications with respect to the rules established by communication specification. Clearly, determining, or validating, whether communications between a device driver and a hardware device conform to a specification is a complex task, often overlooked by operating system providers.
In an effort to address a more general task of determining whether a hardware device is compatible with a computer system, a system and method has been proposed to simulate or emulate an actual hardware device with software, and to provide an automated testing environment to determine the device's compatibility with the operating system. This system and method, set forth in commonly assigned and U.S. Pat. No. 7,181,382, entitled System and Method for Testing, Simulating, and Controlling Computer Software and Hardware, is incorporated herein by reference. According to this novel approach for determining whether a hardware device is compatible with a computer system, a particular hardware device is emulated in software. Communications from a device driver written for the hardware device are intercepted and may be redirected to the emulated hardware device. Similarly, the emulated hardware device responds with information as would an actual hardware device, and those communications are routed to the device driver.
While the above-incorporated reference includes a system that intercepts and redirects the communications between a device driver and a hardware device, it is not adapted to evaluate the communications themselves, and in particular, to determine whether the communications conform to a predetermined communication specification.
In light of the above-described issues relating to hardware compatibility with computing devices, and more particularly relating to validating whether a device driver and hardware device communicate according to an established specification, a need exists for a system and method for validating whether communications between a hardware device and a device driver conform to a specification. The present invention addresses these and other issues relating to the prior art.